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ABSTRACT 

The traffic-adaptive medium access protocol (TRAMA) is 
introduced for energy-efficient collision-free channel access 
in wireless sensor networks. TRAMA reduces energy con- 
sumption by ensuring that unicast, multicast, and broad- 
cast transmissions have no collisions, and by allowing nodes 
to switch to a low-power, idle state whenever they are not 
transmitting or receiving. TRAMA assumes that time is 
slotted and uses a distributed election scheme based on in- 
formation about the traffic at each node to determine which 
node can transmit at a particular time slot. TRAMA avoids 
the assignment of time slots to nodes with no traffic to send, 
and also allows nodes to determine when they can become 
idle and not listen to the channel using traffic information. 
TRAMA is shown to be fair and correct, in that no idle 
node is an intended receiver and no receiver suffers colli- 
sions. The performance of TRAMA is evaluated through 
extensive simulations using both synthetic- as well as sensor- 
network scenarios. The results indicate that TRAMA out- 
performs contention-based protocols (e.g., CSMA, 802.11 
and S-MAC) as well as scheduling-based protocols (e.g., 
NAM A) with significant energy savings. 

Categories and Subject Descriptors 

C.2.1 [Network Architecture and Design]: Wireless 
Communication; C.2.2 [Computer- Communication Net- 
works]: Network Protocols 

General Terms 

Algorithm, Design, Performance 
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1. INTRODUCTION 

Sensor networks typically refer to large ensembles of in- 
terconnected nodes that have processing and communication 
capabilities, and one or more sensing devices (e.g., thermis- 
tors, magnetometers, light detectors). The deployment of 
such networks is usually done in an ad-hoc manner (e.g., 
dropping sensors from an aircraft on the field) which im- 
plies that sensor-network nodes need to self-organize into a 
multi-hop wireless network. Many of the large-scale sensor 
networks of the future will consist of battery-powered sen- 
sor nodes whose battery may be difficult to recharge, or that 
the nodes themselves may be so cheap that recharging them 
may not be cost effective. 

As the hardware for sensor nodes has become affordable, 
sensor networks have emerged as an ideal solution to a num- 
ber of applications in both civilian and military scenarios, 
including monitoring and surveillance of large, remote or 
inaccessible areas over extended periods of time. However, 
a major challenge facing the development and eventual de- 
ployment of large-scale sensor networks is the scheduling of 
transmissions among nodes in a way that (a) is self adap- 
tive to changes in traffic, node state, or connectivity; and 
(b) prolongs the battery life of each node. 

Background 

There is an extensive body of work on MAC (medium ac- 
cess control) protocols for multihop wireless networks, dat- 
ing back to the DARPA packet radio program (e.g., [16, 17, 
18, 7, 8, 11]). These MAC protocols can be categorized as 
contention- and schedule-based. 

The best-known example of contention-based protocols is 
the distributed coordination function (DCF) of the IEEE 
802.11b standard [13], which uses the carrier sense mul- 
tiple access (CSMA) technique combined with a four- way 
handshake that attempts to avoid collisions of data pack- 
ets. In terms of energy consumption, a key limitation of 
traditional contention- based schemes is that nodes consume 
energy needlessly when they are idle (i.e., not transmit- 
ting or receiving) as well as when collisions occur. Until 
recently, very little work has been reported on contention- 
based schemes that focus on energy efficiency. 
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PAMAS [20] is one of the earliest contention- based pro- 
posals to address power efficiency in channel access. PAMAS 
saves energy by attempting to avoid over-hearing among 
neighboring nodes. To achieve this, PAMAS uses out-of 
channel signaling. Woo and Culler [23] address variations of 
CSMA tailored for sensor networks, and propose an adaptive 
rate control mechanism to achieve fair bandwidth allocation 
among sensor network nodes. In the power save (PS) mode 
in IEEE 802.11 DCF, nodes sleep periodically. Tseng et 
al. [22] investigated three sleep modalities in 802. 1 1 DCF in 
multi-hop networks. The sensor-MAC protocol [24], or S- 
MAC, exhibits similar functionality to that of PAMAS and 
the protocol by Tseng et al.. Like the other approaches, S- 
MAC avoids overhearing and nodes periodically sleep. How- 
ever, unlike PAMAS, S-MAC uses in-line signaling, and un- 
like modalities of the PC mode in 802.11 DCF, neighboring 
nodes can synchronize their sleep schedules. 

The probability of collisions of control or data packets 
in any contention-based scheme increases with the offered 
load, which degrades channel utilization and further reduces 
battery life. This motivates the need for establishing trans- 
mission schedules statically or dynamically to allow nodes 
to receive data packets without collisions. The transmis- 
sion schedule established in a wireless network can be topol- 
ogy independent or topology dependent [6, 15, 19, 5]. The 
scheduled-access MAC protocol described by Sohrabi and 
Pottie [21] uses a combination of TDMA and FDMA or 
CDMA for accessing the channel. The main drawback of 
this scheme is that, like most fixed scheduling mechanisms, 
time slots are wasted if a node does not have any data to 
send to the intended receiver. 

The Node Activation Multiple Access (NAMA) [5] uses a 
distributed election algorithm to achieve collision-free trans- 
missions. For each time slot, NAMA selects only one trans- 
mitter per two-hop neighborhood and hence all nodes in 
the one-hop neighborhood of the transmitter are able to re- 
ceive data collision- free. However, NAMA does not address 
energy conservation. In fact, very few proposals, if any, im- 
plement energy-aware medium access scheduling. 

Focus 

Section 2 introduces the TRaffic-Adaptive Medium Access 
(TRAM A) protocol, which provides energy-efficient conflict- 
free channel access in wireless sensor networks. Channel ac- 
cess in TRAMA is energy efficient while maintaining good 
throughput, acceptable latencies, and fairness. Energy effi- 
ciency is attained by (1) transmission schedules that avoid 
collisions of data packets at the receivers, and (2) having 
nodes switch to low power radio mode when there is no data 
packets intended for those nodes. Adequate throughput and 
fairness is achieved by means of a transmitter-election algo- 
rithm that is inherently fair and promotes channel reuse as a 
function of the competing traffic around any given source or 
receiver. TRAMA derives collision- free transmission sched- 
ules based on the identifiers of nodes one and two hops away, 
the current time slot, and traffic information that specifies 
which node intends to transmit to which other node. Hence, 
the "sleep schedule" of a node is a direct function of the 
traffic going through the node and its neighbors, and is syn- 
chronized automatically when nodes exchange information 
about their identifiers and their traffic. 

TRAMA is similar to the Node Activation Multiple Ac- 
cess (NAMA) protocol [5], in that the identifiers of the nodes 



within a two-hop neighborhood are used to give conflict- 
free access to the channel to a given node during a par- 
ticular time slot. However, NAMA does not address en- 
ergy efficiency, and nodes that are not transmitting switch 
to receiver mode. In contrast, TRAMA addresses energy 
efficiency by having nodes going into sleep mode if they 
are not selected to transmit and are not the intended re- 
ceivers of traffic during a particular time slot. Furthermore 
TRAMA uses traffic information to influence the schedules, 
which makes TRAMA far more adaptive to the sensor net- 
work application at hand. For instance, an event-tracking 
application will likely generate data only when an event is 
detected. On the other hand, monitoring applications may 
generate data continuously. In either case, TRAMA can 
adapt its schedules accordingly, delivering adequate perfor- 
mance and energy efficiency. 

In contrast to prior MAC protocols proposed for sensor 
networks, TRAMA provides support for unicast, broadcast 
and multicast traffic (i.e., transmitting to only a set of one- 
hop neighbors). TRAMA differs from S-MAC (which also 
provides explicit energy conservation mechanisms) in two 
fundamental ways: (1) TRAMA is inherently collision-free 
as its medium access control mechanism is schedule-based 
as opposed to S-MAC's which is contention-based; and (2) 
TRAMA 's uses an adaptive, dynamic approach based on 
current traffic patterns to switch nodes to low power mode, 
while S- MAC's scheme is static based on a pre-defined duty 
cycle. 

In Section 3, we discuss why TRAMA is fair and provides 
transmission schedules in which no collisions, idle listening, 
and idle senders occur. 

We evaluate the performance of TRAMA through exten- 
sive simulations using the Qualnet network simulator [3]. 
We compare the performance of TRAMA against three 
contention-based MAC protocols, namely CSMA, 802.11's 
DCF, and S-MAC, and also against NAMA, which is a good 
example of collision-free channel access based on dynamic 
schedules. Section 4 describes our simulation setup, and 
Section 5 presents simulation results. Our simulation results 
show that TRAMA exhibits superior end-to-end throughput 
(around 40% over S-MAC and CSMA and around 20% for 
802.11) for both synthetic traffic models and traffic mod- 
els that are sensor-network specific, because it avoids colli- 
sions due to hidden terminals. Our results also show that 
TRAMA achieves significant energy savings (since nodes can 
sleep for up to 87% of the time) and higher throughput. Sec- 
tion 6 presents concluding remarks. 

2. TRAMA 

2.1 Protocol Overview 

TRAMA employs a traffic adaptive distributed election 
scheme that selects receivers based on schedules announced 
by transmitters. Nodes using TRAMA exchange their two- 
hop neighborhood information and the transmission sched- 
ules specifying which nodes are the intended receivers of 
their traffic in chronological order, and then select the nodes 
that should transmit and receive during each time slot. Ac- 
cordingly, TRAMA consists of three components: the 
Neighbor Protocol (NP) and the Schedule Exchange Proto- 
col (SEP), which allow nodes to exchange two-hop neighbor 
information and their schedules; and the Adaptive Election 
Algorithm (AEA), which uses neighborhood and schedule 
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information to select the transmitters and receivers for the 
current time slot, leaving all other nodes in liberty to switch 
to low-power mode. 

TRAMA assumes a single, time-slotted channel for both 
data and signaling transmissions. Figure 1 shows the overall 
time-slot organization of the protocol. Time is organized as 
sections of random- and scheduled-access periods. We re- 
fer to random-access slots as signaling slots and scheduled- 
access slots as transmission slots. Because the data rates 
of a sensor network are relatively low, the duration of time 
slots is much larger than typical clock drifts. For exam- 
ple, for a 115.2 Kbps radio, we use a transmission slot of 
approximately 46ms to transmit 5 12- byte application layer 
data units. Hence, clock drifts in the order of ms can be tol- 
erated, and yet typically clock drifts are in the order of mi- 
croseconds or even less. This allows very simple timestamp 
mechanisms (e.g., [10]) to be used for node synchronization. 
When much smaller clock drifts must be assumed and more 
expensive nodes can be used, nodes can be time synchro- 
nized using techniques such as GPS [9]. Accordingly, in the 
remainder of our description of TRAMA, we simply assume 
that adequate synchronization is attained. 

NP propagates one-hop neighbor information among neigh- 
boring nodes during the random access period using the 
signaling slots, to obtain consistent two-hop topology in- 
formation across all nodes. As the name suggests, during 
the random access period, nodes perform contention-based 
channel acquisition and thus signaling packets are prone 
to collisions. 

Transmission slots are used for collision- free data exchange 
and also for schedule propagation. Nodes use SEP to ex- 
change traffic-based information, or schedules, with neigh- 
bors. Essentially, schedules contain current information on 
traffic coming from a node, i.e., the set of receivers for the 
traffic originating at the node. A node has to announce 
its schedule using SEP before starting actual transmissions. 
SEP maintains consistent schedule information across neigh- 
bors and updates the schedules periodically. 

AEA selects transmitters and receivers to achieve collision- 
free transmission using the information obtained from NP 
and SEP. This is the case, because electing both the trans- 
mitter and the receiver (s) for a particular time slot is a ne- 
cessity to achieve energy efficiency in a collision- free trans- 
mission schedule. Random transmitter selection leads to col- 
lisions, and electing the transmitters and not the receivers 
for a given time slot leads to energy waste, because all the 
neighbors around a selected transmitter have to listen in the 
slot, even if they are not to receive any data. Furthermore, 
selecting a transmitter without regard to its traffic leads 
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to low channel utilization, because the selected transmit- 
ter may not have any data to send to the selected receiver. 
Hence, AEA uses traffic information (i.e., which sender has 
traffic for which receivers) to improve channel utilization. 

The length of a transmission slot is fixed based on the 
channel bandwidth and data size. Signaling packets are usu- 
ally smaller than data packets and thus transmission slots 
are typically set as a multiple of signaling slots to allow for 
easy synchronization. In our implementation, transmission 
slots are seven times longer than signaling slots. 

2.2 Access Modes and the Neighbor Protocol 

In sensor networks, nodes may fail (e.g., power drained) or 
new nodes may be added (e.g., additional sensors deployed). 
To accommodate topology dynamics, TRAMA alternates 
between random- and scheduled access. 

TRAMA starts in random access mode where each node 
transmits by selecting a slot randomly. Nodes can only join 
the network during random access periods. The duty cycle 
of random- versus scheduled access depends on the type of 
network. In more dynamic networks, random access periods 
should occur more often. In more static scenarios, the inter- 
val between random access periods could be larger, because 
topology changes need to be accommodated only occasion- 
ally. In the case of sensor networks, there is very little or no 
mobility, depending on the type of application. Hence, the 
main function of random access periods is to permit node ad- 
ditions and deletions. Time synchronization could be done 
during this period. During random access periods, all nodes 
must be in either transmit or receive state, so they can send 
out their neighborhood updates and receive updates from 
neighbors. Hence, the duration of the random access period 
plays a significant role in energy consumption. 

During random access periods, signaling packets may be 
lost due to collisions, which can lead to inconsistent neigh- 
borhood information across nodes. To guarantee consistent 
neighborhood information with some degree of confidence, 
the length of the random access period and the number of 
retransmissions of signaling packets are set accordingly. In 
[4], it is shown that, for a network with an average of N 
two-hop neighbors, the number of signaling packet retrans- 
missions should be 7 and the retransmission interval 1.44* N 
to guarantee packet delivery of 99%. Thus, the length of the 
random access period will then be 7* 1.44 * N. 

NP gathers neighborhood information by exchanging small 
signaling packets during the random access period. Fig- 
ure 2(a) shows the format of the header of a signaling packet. 
Signaling packets carry incremental neighborhood updates 
and if there are no updates, signaling packets are sent as 



"keep-alive" beacons. Each node sends incremental updates 
about its one-hop neighborhood as a set of added and deleted 
neighbors. These signaling packets are also used to main- 
tain connectivity between the neighbors. A node times out a 
neighbor if it does not hear from that neighbor for a certain 
period of time. The updates are retransmitted such that we 
ensure 0.99 probability of success. Because a node knows 
the one- hop neighbors of its one- hop neighbors, eventually 
consistent two-hop neighborhood information makes its way 
across the network. 

2.3 Schedule Exchange Protocol 

SEP establishes and maintains traffic-based schedule in- 
formation required by the transmitter (i.e., slot re- use) and 
receiver (i.e., sleep state switching) selection. A node's sched- 
ule captures a window of traffic to be transmitted by the 
node. This information is periodically broadcast to the 
node's one-hop neighbors during scheduled access. 

Schedule generation works as follows. Each node com- 
putes a schedule-interval based on the rate at which 
packets are produced by the higher layer application. The 
schedule-interval of a node represents the number of 
slots for which the node can announce the schedule to its 
neighbors according to the current state of its MAC-layer 
queue. The node then pre-computes the number of slots in 
the interval [t,t + schedule-interval) for which it has the 
highest priority among its two-hop neighbors (contenders), 
which we call "winning slots" . Because these are the slots 
for which the node will be selected as the transmitter, 
the node announces the intended receivers for these slots. 
Alternatively, if a node does not have enough packets to 
transmit, it announces that it gives up the corresponding 
slot(s). Other nodes that have data to transmit can make 
use of these "vacant" slots. A node's last winning slot in 
this interval is reserved for broadcasting the node's schedule 
for the next interval. For example, suppose that node tt's 
schedule-interval is 100 slots. During time slot 1000, u 
computes its winning slots between [1000, 1100]. Let us as- 
sume that these slots are 1009, 1030, 1033, 1064, 1075, and 
1098. Node u uses slot 1098, its last winning slot in this in- 
terval, to announce its next schedule by looking ahead from 
[1098, 1198], and so on. The time corresponding to the last 
winning slot is fixed as the lifetime for the schedule. 

Nodes announce their schedule via schedule packets. Be- 
cause nodes have two-hop topology information obtained 
through NP, there is no need to send receiver addresses in 
the schedule packet. Instead, nodes convey intended receiver 
information using a bitmap whose length is equal to the 
number of one-hop neighbors. Each bit in the bitmap corre- 
sponds to one particular receiver ordered by their identities. 
The total number of receivers supported by this scheme de- 
pends on the size of the data slot and the number of slots 
for which receivers are announced. 1 For example, a node 
with four one-hop neighbors with identities 14, 7, 5 and 4 
will have a bitmap of size four with first MSB correspond- 
ing to node 14, second MSB to node 7. An advantage of 
using bitmaps is the ease with which broadcast and mul- 
ticast communication can be supported. To broadcast a 
packet, all bitmap bits are set to 1, indicating that all one- 
hop neighbors are intended receivers of the packet. If the 

1 Assuming the schedule is announced for 16 slots, the 
scheme can support 256 or 512 neighbors for a 512 or 1024 
byte transmission slot size respectively. 



packet needs to be multicast to just 14 and 4, then only 
these bits are set in the bitmap. A node forms the bitmap 
for the winning slots based on the current traffic informa- 
tion for its queue. If the node's queue size is smaller than 
the number of bitmaps contained in the schedule, some of 
the winning slots will go unused. For these 'Vacant" slots, 
the node announces a zero bitmap. Slots with zero bitmaps 
could potentially be used by some other node in the two-hop 
neighborhood. The slot after which all the winning slots go 
unused is called ChangeOver slot. All unused slots happen 
contiguously toward the end before the last winning slot, 
which is reserved for announcing the next schedule. This 
maximizes the length of sleep periods. 

Figure 3 shows the schedule packet format. Source Addr 
is the address of the node announcing the schedule, timeout 
is the number of slots for which the schedule is valid (start- 
ing from the current slot), width is the length of the neighbor 
bitmap (i.e the number of one-hop neighbors), and numSlots 
is the total number of winning slots (i.e., the number of 
bitmaps contained in the packet). The last winning slot is 
always reserved for announcing the next schedule. 

Additionally, a summary of a node's schedule is sent with 
every data packet. Schedule summaries help minimize the 
effects of packet loss in schedule dissemination. As shown in 
Figure 2(b), the summary includes the schedule's timeout, 
numSlots, and a bitmap corresponding to the winning slots 
in the current interval. The size of the bitmap is numSlots 
and is used to indicate whether the node is transmitting or 
giving up the corresponding slot. Note that, in order not to 
incur excessive overhead, 2 schedule summaries do not carry 
intended receiver information. They are meant to maintain 
synchronization 3 among one-hop neighbor schedules even in 
the face of losses. For example by inspecting the values of 
numSlots and the bitmap in the schedule summary, the re- 
ceiving node can update or re- synchronize its stored schedule 
information. Each schedule has an associated timeout and 
nodes are not allowed to change the schedule until this time- 
out expires. This is required to ensure consistency across 
one-hop neighborhood schedules. 

Nodes maintain schedule information for all their one- hop 
neighbors. The schedule information is consulted whenever 
a node has the highest two-hop priority to decide if the node 
will actually transmit (i.e., it has data to send and thus 
will use the slot) or will give up the slot to another node 
in the neighborhood. Based on this decision, the schedule 
information for the node is updated either using the short 
summary from the data packet (if the node is receiving), or 
assuming transmissions (if the node is sleeping since it is not 
the intended receiver of transmitter). In the latter case, its 
schedule is in an unsynchronized state until the node verifies 
or updates it based on the schedule summary piggybacked 
in a future data packet from that transmitter. 

All nodes listen during the ChangeOver slot of the trans- 
mitter to synchronize their schedule. For instance, if a node 
u keeps assuming transmissions for a particular neighbor 
tx at different timeslots and the neighbor does not trans- 
mit any packets due to a contender that is hidden from u, 
then the schedule at node u for node tx will be unsynchro- 
nized. If node u does not listen during the ChangeOver slot, 

The overhead in the current implementation due to sched- 
ule summary is 6 bytes per data packet. 
3 As demonstrated in Section 3, TRAM A 's correctness is not 
affected by unsynchronized schedules. 
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which is the last slot in the current schedule interval that 
will be used by node tx for transmission, it may assume 
that the node tx is transmitting the data corresponding to 
the ChangeOver slot and update the corresponding sched- 
ule. From now on until the schedule announced by node 
tx expires, node u considers that node tx gives up winning 
slots for re- use. This can lead to collisions if node u tries to 
reuse the winning slot of node tx that is actually used for 
transmission. Hence, schedules among neighbors could be 
unsynchronized only until the ChangeOver slot and a node 
has to listen during the ChangeOver slot of the transmitter. 

It is possible for a node to get some extra slots for trans- 
missions in addition to the original winning slots computed 
while announcing the schedule. To prevent inconsistencies 
and collisions when transmitting the schedule packet, a node 
should always send the schedule packet only on the previ- 
ously announced timeout. Because all the slots after the 
Changeover slot are assumed as give- up slots by the neigh- 
bors, the schedules might be unsynchronized. Hence, trans- 
mitting a schedule before the timeout can potentially cause 
collisions with neighbors. In the following section, we de- 
scribe how these schedule information is used to adapt ively 
decide the node state. 

2.4 Adaptive Election Algorithm 

In the original NCR algorithm [5], a node is selected to 
transmit if it has the highest priority among its contending 
set Node u's contending set is the set of all nodes that are 
in tz's two-hop neighborhood. Node it's priority at time slot 
t is defined as the pseudo-random hash of the concatenation 
of node u's identity and t, or 

prio(u, t) = hash(u © t) (1) 

Assuming that node identities are unique and nodes are 
synchronized, all nodes compute the same priority value at 
any given time slot. However, if the selected node does not 
have any data to send, then the slot is wasted. Furthermore, 
nodes are free to transmit to any one-hop neighbor, because 
there is no sleep state in NCR. 

For energy efficiency, TRAMA switches nodes to sleep 
state whenever possible, and attempts to re-use slots that 
are not used by the selected transmitter for bandwidth ef- 
ficiency. A selected node may give up its transmission slot 



if it does not have any packets to send; this slot could then 
be used by another node. Nodes exchange current traffic 
information with their neighbors to make effective use of 
low-power, idle radio mode and accomplish slot re- use. 

At any given time slot t during the scheduled access pe- 
riod, the state of a given node u is determined based on 
u's two-hop neighborhood information and the schedules 
announced by it's one- hop neighbors. Possible states are: 
transmit (TX), receive (RX), and sleep (SL). 

At any given slot t, a node u is in the TX state if: (1) it 
has the highest priority, i.e., prio(u, t) among its contending 
set and (2) u has data to send. 

A node is in the RX state when it is the intended re- 
ceiver of the current transmitter. Otherwise, the node can 
be switched off to the SL state, because it is not participat- 
ing in any data exchange. This means that, if a node is not 
the selected transmitter, it will decide whether it needs to 
be in RX state by consulting the schedule sent out by the 
selected transmitter. If the transmitter does not have traffic 
destined for that node in the current slot, the node can then 
sleep. 

Each node executes AEA to decide its current state ( TX, 
RX, or SL) based on current node priorities (within its 
two-hop neighborhood) and also on the announced schedules 
from one-hop neighbors. The algorithm's pseudo-code is 
provided in Figure 5. Table 1 lists some basic terminology 
and notation used in the description of AEA. 

The state of a node depends on the Absolute Winner and 
the announced schedules from its one-hop neighbors. From 
node it's point of view, the Absolute Winner at any given 
time slot t can be: (1) node u itself, (2) node v that lies 
in the two-hop neighborhood of node u in which case the 
Alternate Winner atx(u) needs to be accounted for if hidden 
from node v, or (3) a node w that lies in node u's one-hop 
neighborhood. 

Whenever a node becomes an Absolute Winner for a par- 
ticular timeslot and has announced a non-zero bitmap for 
this slot, it knows that no other node in its two-hop neigh- 
borhood will be transmitting in this slot. Thus, the node 
can transmit collision- free to its intended receiver (s). When 
a node is not an Absolute Winner, it is not certain who the 
actual transmitter for a particular slot is. For example, con- 
sider the topology shown in Figure 4. Let D be the node 



Table 1: Notations and terminologies 



N2(u) 


Set of neighbors of node u which are two- hops away. 


Nl(tx) 


Set of neighbors of node u which are one-hop away. 


CS(u) 


li's Contending Set is the set of nodes in u's two-hop neighborhood such that 
{uUNl(ti)UN2(u)}. 


tx{u) 


Absolute Winner is the node with the highest priority m CS(u). 


atx(u) 


Alternate Winner is the node which has the highest priority among it's one-hop 
neighbors, i.e., over the set {u U Nl(u)}. 


PTX(ix) 


Possible Transmitter Set is the set of all nodes in {u U Nl(u) - atx(u)} that 
satisfy the condition given in Equation 2. 


NEED(u) 


Need Contender Set is the set of nodes in {PTX(tt) U u) that are in need of 
additional transmission slots. 


ntx(u) 


Need Transmitter is the node with the highest priority among the set of nodes 
NEED (it) containing valid synchronized schedule. 



with highest priority in node B's two-hop neighborhood in a 
given time slot and let A be the highest 2-hop priority node 
in node A's two-hop neighborhood. Both A and D could 
transmit in the time slot because they are Absolute Win- 
ners; the Absolute Winner to node B is node D. Therefore, 
if B looks at its schedule information for D and finds out 
that it is not £)'s intended receiver for the current slot, it 
will decide to switch to SL mode. However, if it happens to 
be A's intended receiver, it will end up missing v4's trans- 
mission. Hence, before switching to SL mode, a node must 
also account for the Alternate Winner. This potential in- 
consistency occurs only if the Alternate Winner is hidden 
from the Absolute Winner i.e., they are three hops away. 

To avoid wasting slots when the Absolute Winner has no 
data to send, TRAMA keeps track of nodes that could use 
extra slots to send their data. It first computes the set of 
nodes that can possibly transmit at the current time slot. 
They are kept in the Possible Transmitter Set, which con- 
tains all nodes in the one-hop neighborhood that can pos- 
sibly transmit without any collision. A node can transmit 
without collisions only if it has the highest priority in the 
two- hop neighborhood. Hence, a node checks for possible 
transmitters in the one-hop neighborhood using the avail- 
able information. Because a node cannot know the entire 
two-hop neighborhood of its one-hop neighbors, it can only 
check if this neighbor has the highest priority among the 
nodes that are known to be the neighbor's two-hop neigh- 
bor. In other words, for a one-hop neighbor of node u, say 
node y, the following condition should be satisfied to be in 
the PTX(u): 

prio(y) > prio(x)Vx,x € Nl(Nl(y)) and x £ Nl(y)) (2) 

The Need Contender Set is the subset of the Possible Trans- 
mitter Set and contains only those nodes that have data to 
send. Nodes for which node u does not have (valid) sched- 
ules are also included in this set as node u does not know 
whether these nodes have data to send. 

The Absolute Winner is the assumed transmitter for a 
node, unless the Alternate Winner is hidden from Absolute 
Winner and it belongs to the Possible Transmitter Set In 
the latter case, the Alternate Winner is the assumed trans- 
mitter. Whenever the assumed transmitter gives up, the 
Need Contender Set is checked and the node with the high- 
est priority within this set is selected as the Need Transmit- 
ter ntx(u). Nodes that are not in the schedule listed by the 
assumed transmitter can switch to SL mode to save energy. 



This is especially beneficial in scenarios in which only a few 
nodes generate data at a time and data are destined to small 
subset of receivers. 

3. TRAMA CORRECTNESS 

TRAMA is correct, if it avoids collisions and transmis- 
sions to a sleeping node - both can cause packet losses. A 
node can, however, assume that some of its neighbors is 
transmitting when the transmission does not actually hap- 
pen. Though this will lead to increased energy consumption 
because nodes may be in receive mode unnecessarily, it does 
not affect the correctness of the algorithm. 

Arguing for collision freedom is simple. The only two ways 
in which a node u can be a transmitter is through line 4 in 
the pseudo-code, where the node is the Absolute Winner 
and line 34 in the pseudo-code, where the node is the Need 
Transmitter. In both cases, there cannot be a node two- 
hops away from node u and transmitting. This follows from 
Equation 2 and by the definition of Absolute Winner. Hence, 
there can be no collisions due to transmissions from two- 
hop neighbors. Assuming that schedules are synchronized 
(which allows a node to know exactly whether the elected 
one-hop neighbor uses the slot or gives it up for re-use) and 
by virtue of the election mechanism, no other node that is 
one-hop away from node u can transmit. Hence, there can 
be no collisions due to a neighbor transmitting at the same 
time and the protocol maintains collision freedom at all the 
times. 

To show that TRAMA never looses a packet due to an in- 
valid state assignment (i.e., a node transmitting to a sleep- 
ing node), it is enough to show that, whenever a node u 
goes to sleep assuming that some node v is transmitting in 
its one-hop neighborhood (given that node u is not the in- 
tended receiver of node v), then no other node except node 
v can transmit in the one-hop neighborhood. A node always 
considers the transmitter to be either the Absolute Winner, 
the Alternate Winner, or the Need Transmitter. Because a 
node can receive only from a node that is one-hop away, the 
Absolute Winner should be a one-hop neighbor. Hence, if 
a node assumes that a neighbor is transmitting, it is either 
the Alternate Winner or the Need Transmitter. 

Consider the case in which node u decides to sleep dur- 
ing a time slot t assuming that node v is the transmitter. 
Hence, node v has the highest priority among the two-hop 
neighbors of node v known to node u and among the one- 
hop neighbors of node u that have data to send. Let node 



1 Compute tx(u), atx(u) and ntx(u) 

2 if (u — tx(u)) then 

3 if (u.isScheduleAnnouncedForTx = TRUE) then 

4 let u. state — TX 

5 let u.receiver — u.reported.rxld 

6 Transmit the packet and update the announced schedule 

7 else if (u.giveup — TRUE) then 

8 call H and leNeedTYansmiss ions 

9 endif 

10 else if (tx(u) € Nl(u)) then 

11 if (tx(u).announcedScheduleIsValid — TRUE AND tx(u).announcedGiveup — TRUE) then 

12 call HandleNeedTYansmissions 

13 else if (tx(u).announcedScheduleIsValid = FALSE OR tx(u).announcedReceiver = it) then 

14 let u.mode = RX 

15 else 

16 let u.mode = SL 

17 Update schedule for tx(u) 

18 endif 

19 else 

20 if (atx(u) hidden from tx(u) AND atx{u) € PTX(w)) then 

21 if (atx(u).announcedScheduleIsValid — TRUE AND atx(u).announcedGiveup = TRUE) then 

22 call HandleNeedTYansmissions 

23 else if (atx(u).announcedScheduleIsValid = FALSE OR atx(u).announcedReceiver = u) then 

24 let u.mode = RX 

25 else 

26 let u.mode = SL 

27 Update schedule for atx(u) 

28 endif 

29 else 

30 call HandleNeedTYansmissions 

31 endif 

32 procedure HandleNeedTYansmissions 

33 if (ntx(u) = u) then 

34 let u.state = TX 

35 let u.receiver = u.reported.rxld 

36 Transmit the packet and update the announced schedule 

37 else if (ntx(u).announcedScheduleIsValid — FALSE \\ ntx(u) .announcedReceiver = u) then 

38 let u.mode — RX 

39 else 

40 let u.mode — SL 

41 Update the schedule for ntx(u) 

42 endif 



Figure 5: Pseudo-code description of AEA 



w be the actual transmitter for the time slot t in the one- 
hop neighborhood of node u. This means that node w has 
the highest priority among the two-hop neighbors of node 
w and it has the highest priority among the one-hop neigh- 
bors of node w that have data to send. Node w can either 
be a one-hop neighbor to node v or a two-hop neighbor to 
node v. If node w is a one-hop neighbor of node then 
node w should have higher priority than node v. Because, 
node v and node w are neighbors of node u and the sched- 
ules are synchronized, it contradicts the fact that node v has 
the highest priority among the one-hop neighbors of node u 
that have data to send. Hence, node w cannot be the actual 
transmitter. When node w is a two-hop neighbor to node 
v, it should have higher priority than node which contra- 
dicts the fact that node v has the highest priority among 
the two-hop neighbors of node v known to node u. Hence, 
there cannot be a transmitter, node w in the one-hop neigh- 
borhood of node u. 

Schedules can get unsynchronized for different reasons, 
and TRAM A is also correct in the face of unsynchronized 
schedules. For example when a node assumes that node v 
is transmitting and decides to sleep, node v may not trans- 
mit. This will make the schedules unsynchronized and the 



ChangeOver slot for node v is reached earlier. The require- 
ment that all the nodes should listen during the ChangeOver 
slot of the neighbors, prevents a node going to sleep or trans- 
mit state assuming that the neighbor is giving up and en- 
sures correctness. Whenever a node assumes that a neighbor 
is transmitting a data to it, the schedules are updated only 
after receiving the data from the neighbor using the schedule 
summary. Hence, packet losses due to transmission errors 
can cause the schedules to be unsynchronized and forces 
a node to listen whenever the unsynchronized neighbor is 
elected for transmission. This continues until the node re- 
ceives a data packet from the unsynchronized neighbor, and 
also prevents invalid state assignment. Hence, TRAM A is 
correct even when the schedules are not synchronized. 

4. EXPERIMENTAL SETUP 

Through simulations, we evaluate TRAMA and compare 
its performance against both contention- and scheduling- 
based protocols. While we consider Carrier-Sense Multiple 
Access (CSMA) [16], IEEE802.il [13] and S-MAC [24] as 
example contention- based protocols, we use Node Activation 
Multiple Access (NAMA) [5] as example scheduling-based 
protocol. 



We used Qualnet [3] as our simulation platform and we 
present the results for a variety of scenarios. The underlying 
physical layer model used for all the experiments was based 
on the TR1000, a typical radio used in sensor networks. The 
TR1000 [2], the radio used by the UC Berkeley Motes [1], 
are short range, low data-rate (a maximum of 115.2KBPS) 
radios with built-in support for low-power sleep state. The 
average power consumption in transmit, receive and sleep 
modes is 24. 75m W, 13.5mW and 15/iVK, respectively. The 
maximum transition time for switching is 20liS. The modu- 
lation type used in the physical layer is ASK and the receiver 
threshold is —75dBm. Fifty nodes are uniformly distributed 
over a 500m x 500m area in all the experiments. The trans- 
mission range of each node is 100m and the topology is such 
that the nodes have 6 one-hop neighbors on average. The 
average size of the two-hop neighborhood for this network is 
17 nodes. Two different types of traffic load are considered 
in our study. We used a scenario in which node traffic is 
statistically generated based on a exponentially distributed 
inter- arrival time. We chose this to stress- test protocol per- 
formance for different arrival rates. We also test TRAMA 's 
performance when driven by data gathering applications, 
which are considered typical of sensor networks. Below, we 
describe these traffic scenarios as well as other simulation 
parameters in detail. 

4.1 Protocol Parameters 

In both scenarios we fixed up the schedu le.jnterval to 
be 100 transmission slots for TRAM A. The maximum size of 
a signaling packet is fixed at 128 bytes which gives to a slot 
period of 6.82ms with guard time to take care of switching. 
Transmission slots are seven times longer than the signaling 
slots supporting a maximum data fragment size 896 bytes. 
The random access period is fixed to 72 transmission slots 
and is repeated once every 10000 transmission slots. 

S-MAC is a contention-based channel access protocol and 
it uses periodic sleep intervals to conserve energy. Sleep 
schedules are established using SYNC packets which are 
exchanged once every sync.interval. The duty cycle de- 
termines the length of the sleep interval. 

We set sync.interval as lOsec and we varied the duty 
cycle (10% and 50%). All the nodes are time synchronized 
and hence we favored S-MAC by allowing the listen and 
sleep periods synchronized across the entire network. We 
also observed that S-MAC needed larger time to set up the 
listen/sleep schedules with the neighbor. This is because S- 
MAC does not have a proper neighbor discovery protocol, 
it has to rely on the SYNC packets for doing this. SYNC 
packets are transmitted only once and are transmitted unre- 
liably. Hence, a large warmup time of 20sec is allowed for the 
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Figure 7: Average packet delivery ratio for synthetic 
traffic 



neighbor information to settle down. Because the queuing 
delay for the scheduling- type MAC's is higher, we allowed 
some more time for delivering the queued packets before 
ending the simulation. The simulation is run for 400sec and 
the results are averaged over multiple runs. 

4.2 Synthetic Data Generation 

The objective of this experiment is to measure the per- 
formance of TRAMA when all the nodes in the network 
generate traffic based on some statistical distribution. We 
used exponential inter-arrival for generating data and varied 
the rate from 0.5 to 2.5 seconds. A neighbor is randomly 
selected as a next-hop every time a node transmits a packet. 
We tested both unicast and broadcast data generation sep- 
arately. The performance metrics are: 

• Average Packet Delivery Ratio: It is the ratio of 
number of packets received to the number of packets 
sent averaged over all the nodes. For broadcast traffic 
a packet is counted to be received only if it is received 
by all the one-hop neighbors. 

• Percentage Sleep Time: It is the ratio of the num- 
ber of sleeping slots to the total number of slots aver- 
aged over the entire network. 
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Figure 8: Average queuing delay for synthetic traffic 

• Average queuing Delay: Average delay for the 
packet to be delivered to the receiver 

• Average Sleep Interval: This is the average length 
of sleeping interval. This measures the number of ra- 
dio mode switching involved. Frequent switching can 
waste energy due to the transient power consumption 
involved in switching. 4 

4.3 Data-Gathering Application 

We assume a sink is collecting data from all the sensors 
for these experiments. The sink sends out a broadcast query 
requesting data from all the sensors. The sensors respond 
back with the data, which are generated periodically to the 
sink. We implemented a simple reverse-path routing to for- 
ward the data from the sensors to the sink. Figure 6 shows 
the three different scenarios considered for this study. Data- 
collection node or sink is placed in the corner for the first 
case and in the middle for the second case. 

All the sensors respond with periodically generated data 
in both cases. Because data aggregation [14] or grouping 
data to minimize traffic, are advantageous, we also emulated 
data aggregation in a third case. Here, only the nodes at the 
edge generate traffic and we assume that the nodes do data 

Measurements for 802.11 based radios are available in [12]. 



Figure 9: Energy savings and average sleep interval 
for synthetic traffic 

aggregation and appends its reading to the parent node. 
To measure performance in these experiments we use the 
metrics defined for the synthetic case. The average packet 
delivery ratio is measured as the ratio of total number of 
data received by the sink to the total number of data sent 
by all the sensors, unlike the per-hop delivery ratio used for 
synthetic traffic generation. 

5. SIMULATION RESULTS 
5.1 Synthetic Traffic 

The packet delivery ratio, average queuing delay, percent- 
age of sleep time, and average length of sleep intervals for 
synthetic traffic scenarios are shown in Figure 7, Figure 8, 
Figure 9(a) and Figure 9(b), respectively. We present re- 
sults for S-MAC using two different duty cycles, namely 50% 
and 10%. Our results indicate that, in general, schedule- 
based MACs based on NCR achieve better delivery than 
IEEE802.il, CSMA and S-MAC. The main reason for the 
improvement in delivery is the collision freedom guaran- 
teed at all times during data transmission. The effect is 
more noticeable when all nodes generate broadcast traffic. 
In CSMA, S-MAC and IEEE802.il, broadcasting is unreli- 
able and susceptible to hidden-terminal collisions. This re- 



duces broadcast delivery significantly when we increase the 
load as our results indicate. For IEEE802.il and S-MAC, 
the RTS/CTS /DATA /ACK exchange for unicast traffic im- 
proves delivery when compared to broadcast traffic because 
it reduces hidden-terminal collisions by doing collision avoid- 
ance. 

Schedule-based MACs, on the other hand, incur higher 
average queuing delays. We should point out that when 
measuring average delay, we account for the delay of packets 
successfully delivered. However, TRAMA and NAM A de- 
liver more packets than contention-based MACs and this will 
reduce the retransmissions at the higher layers. Hence, the 
end-to-end delay perceived by the application will be com- 
parable to that of contention- based protocols. The average 
queuing delay for TRAMA is higher than that of NAMA due 
to the overhead involved in propagating scheduling informa- 
tion. Once every schedulejnterval, a transmission slot 
is used for announcing schedules. This decreases the effec- 
tive channel access probability for data transmission. This 
scenario is not a favorable scenario for traffic-adaptive elec- 
tions, because the traffic is homogeneous across the network 
and all nodes periodically generate traffic. The throughput 
of TRAMA is comparable with that of NAMA and is sig- 
nificantly better than contention- based protocols for both 
unicast and broadcast traffic scenarios. The performance of 
the only other energy-efficient protocol, S-MAC is compara- 
ble with IEEE802.il in terms of throughput. However, the 
delay is slightly higher than that of IEEE802.il or CSMA 
due to the sleep periods, and it increases as the duty cycle of 
the listen periods is decreased. For a duty cycle of 50%, the 
delay of S-MAC is smaller than that of IEEE802.il for the 
unicast-data generation scenario. This is because S-MAC 
frequently switches between sleep and listen modes(average 
sleep interval plotted in Figure 9(b) reflects this) for that 
duty cycle. This is equivalent to a node being awake most 
of the time, and the delay is less because S-MAC does not 
have any contention resolution algorithm. 

The energy savings of TRAMA depend mainly on the traf- 
fic pattern, while the energy savings of S-MAC are depen- 
dent on the duty cycle. The total energy savings depend 
on both percentage sleep time and average length of sleep 
interval. Percentage sleep time metric does not account for 
the performance loss that is possible due to frequent ra- 
dio mode switching. The average length of sleep interval 
quantifies the amount of radio-mode switching involved. A 
higher value of average sleep length is preferred because this 
implies less radio-mode switching and hence more savings. 
The results indicate that the percentage of sleep time is 
less for broadcast traffic when compared to unicast traffic, 
which is intuitive. The percentage sleep time of S-MAC 
increases as the duty cycle decreases. The price paid for 
decreasing the duty cycle is an increase in latency. The 
throughput decreases more steeply for a lower duty cycle as 
traffic increases. For the broadcast packets, a 50% duty cy- 
cle achieves less throughput than 10% duty cycle. Broadcast 
is done by plain carrier sensing and is more prone to hid- 
den terminal collisions. The timing structure for 512 bytes 
data that favors low duty cycle as it reduces the channel 
contention and hence the collisions are reduced. Note that 
a broadcast packet is counted as delivered ONLY if it is 
delivered to all the neighbors. 

Compared with TRAMA, S-MAC with 10% duty cycle 
exhibits higher percentage of sleeping time. But the aver- 
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Figure 10: Corner Sink 



age length of sleep intervals is much lower for S-MAC when 
compared to TRAMA. This reduces the overall energy sav- 
ings due to the overhead involved in mode switching. This 
is the case even though S-MAC is being favored by assum- 
ing that synchronized listen/sleep schedules are established 
across the nodes due to the simulation setup. The perfor- 
mance of TRAMA is not affected by nodes joining at discrete 
intervals because it does not require any synchronization of 
listen/sleep schedules. 

In the subsequent experiments, we only consider S-MAC 
with 10% duty cycle, which has better performance than 
with a 50% duty cycle. 

5.2 Sensor Network Application 

We tested the protocols using a sensor network data gath- 
ering application. One of the nodes in the network is des- 
ignated as the sink and the sink starts sending a broadcast 
query. All nodes receiving a non-duplicate query add the 
sender of the query as the next hop for data forwarding, 
establishing a reverse-shortest path tree with the sink node 
as the root. Figures 10(a), 11(a), and 12(a) show the av- 
erage packet delivery ratio for the corner sink, center sink, 
and edge sink scenarios respectively. Schedule-based MAC 
protocols outperform the contention-based MAC protocols 
in all the cases. The delivery is highest for the scenario 
in which the edge nodes are generating traffic. This is be- 
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cause the overall load in the network is low and well within 
the capacity of the protocols. Delivery to the center sink 
is slightly higher than when corner sink is used because the 
packets need to go through fewer number of hops to reach 
the sink. TRAMA performs much like NAMA and the de- 
crease in throughput due to scheduling overhead is overcome 
by TRAMA's adaptive scheduling approach. The average 
delivery ratio is nearly constant for contention-based proto- 
cols as the variation in the offered load is not high. 

Figures 10(b), 11(b), and 12(b) show the average per- 
hop delay for all the protocols for the sensor scenarios. 
Contention-based protocols outperform scheduling-based 
protocols in terms of delay. This is due to the latency in- 
troduced by random scheduling. Finally we show the per- 
centage sleep time achieved by TRAMA and S-MAC in Fig- 
ure 13(a). The percentage of time nodes can be put to sleep 
increases with decrease in traffic load. The percentage sleep 
time is quite high (as high as 85%) for the edge sink sce- 
nario which has the lowest load. Again the average length 
of the sleep interval is also the highest for this case. This 
clearly shows the benefit of TRAMA's traffic adaptability 
when compared to S-MAC. The average sleep interval of 
TRAMA is significantly higher than that of S-MAC. When 
compared to the edge sink scenario, the percentage sleep 
time is less for the center and corner sink scenarios due to 
the increased load. In the corner sink case, data forwarded 



by the nodes which are closer to the sink is heavier than 
data forwarded by nodes farther away. This reduces sleep 
time for these nodes and hence the overall percentage sleep 
time is lesser than the case where the sink is in the center. 
This also applies to the average length of sleep period shown 
in Figure 13(b). 

6. CONCLUSIONS 

In this paper we presented TRAMA, a new energy-aware 
channel access protocol for sensor networks. TRAMA uses 
traffic-based scheduling to avoid wasting slots when nodes 
do not have data to send and to switch nodes to a low-power 
standby radio mode when they are not intended receivers of 
traffic. 

Through extensive simulations, we compared TRAMA's 
performance against a number of contention- and a schedule- 
based MACs. It is evident from the simulation results that 
significant energy savings (since nodes can sleep for up to 
87% of the time) can be achieved by TRAMA depending on 
the offered load. TRAMA also achieves higher throughput 
(around 40% over S-MAC and CSMA and around 20% for 
802.11) when compared to contention-based protocols since 
it avoids collisions due to hidden terminals. 

In general, schedule-based MACs exhibit higher delays 
than contention-based MACs. TRAMA is well suited for 
applications that are not delay sensitive but require high 
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delivery guarantees and energy efficiency. A typical exam- 
ple is sensor networks used for periodic data collection and 
monitoring applications. In summary, TRAMA achieves 
energy-savings comparable to S-MAC with delivery guar- 
antees comparable to NAM A. 
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